前一篇文章Android NDK——必知必会之Makefile和CMake基本使用语法概述（七）简单介绍了MakeFile和CMake的相关知识，这篇就从小结下在Linux下交叉编译的基本流程。

一个C/C++源文件通常需要经过预处理(preprocessing)、编译(compilation)、**汇编(assembly)**和 链接(linking) 四个流程才会变成可以在系统平台上的可执行文件，但是并不意味着必须要执行四个过程所有对应的命令，以编译main.c为例：

默认情况下，gcc编译器只会使用/lib和/usr/lib这两个目录下的库文件，如果存在一个so不在这两个目录，在编译时候就会出现找不到的情况，幸好还可以在**/etc/ld.so.conf文件中可以指定而外的编译链接库路径**，需要引入第三方的库时也可以在**/etc/ld.so.conf**文件里更新

如上图所示，生成了两个可执行的文件（仅隶属于与当前编译环境所支持的CPU指令集），但是这两个都无法在Android平台上运行（要验证也很简单找一台root了的手机然后把生成的可执行文件push到手机里，接着就像在Linux执行一样直接用命令行运行即可），虽然Android系统也是基于Linux系统的，但是在Linux上编译出来的可执行文件仅支持当前的CPU，很明显不同平台的CPU所支持的指令集是不一样的（即C/C++不跨平台）。这也是前面我们介绍NDK目录下的子目录platforms下每个系统下都有不同架构的子目录，通过NDK提供的这些工具我们就可以编译对应架构的函数库。

所谓交叉编译可以简单理解为在一个平台环境下编译出另一个平台可运行的CPU 指令集的过程（这个概念仅仅是我个人的理解）而NDK 中的toolchains\xxx-linux-androideabi-4.9\prebuilt\windows-x86_64\bin目录则提供了一些列不同CPU 架构的交叉编译工具，我们只要合理配置使用即可，如下图所示： 以上图形只做了两步工作，配置局部环境变量（非必须步骤），使用NDK中提供的工具进行编译，原本我也以为就是需要使用对应的工作进行编译就可以了，而却提示找不到标准库中的头文件，这是因为在C/C++源码中默认链接到的标准库的（相当于是javac 中会有个classpath的环境变量），而当我们使用NDK中的工具进行编译的时候，需要使用NDK提供的对应的头文件，只要在执行编译命令的时候添加上对应的参数即可。所以总结起来使用NDK进行交叉编译主要步骤有：

只要在编译时配置上对应的头文件和库文件目录，即可编译出能成功在Android上可执行的文件，不过这里需要注意的是不同版本的NDK 编译的指令有所不同，我的是在NDK_r16b下编译的，一开始使用 -isystem /usr/local/ndk/android-ndk-r16b/sysroot/usr/include/arm-linux-androideabi/asm 配置时编译报asm/types.h: No such file or directory,原因就是因为 -isystem /usr/local/ndk/android-ndk-r16b/sysroot/usr/include/arm-linux-androideabi/asm这样配置的时候，就回去xxx/asm下去找， 而代码中是include asm/types.h 这样引入的就会去 xxx/asm/asm/types.h查找所以自然出错。简单来说：指定为xxxx， include asm/types.h 就是去xxxx/asm/types.h

库本质上是一种可执行的二进制代码，可以被OS载入到内存中去执行，根据载入内存的时间和流程可以分为静态库（Linux中后缀名为”.a”）和动态库（Linux中后缀名为”.so”）两种：

静态库包含了所有执行的代码，库中所有的函数机器码在编译链接时全部被拷贝到可执行的文件中并被添加到和它链接的每一个程序中，简单来说就是把库文件的代码全部加入到可执行文件中，因此生成的文件比较大（打包成APK也较大），但在运行时也就不再需要库文件了，所以静态库节省时间，不需要再进行动态链接，需要调用的代码直接就在代码内部。不过当静态库中某一个函数改变生活，所有使用这个静态库的程序都得重新编译，适用于内部使用。

动态库在编译链接时并没有把库文件的全部代码加入到可执行文件中，而是在程序运行时由运行时的链接文件加载库，即运行时再动态申请调用进行链接拷贝，gcc在编译时默认使用动态库，动态库能节省空间，如果一个动态库被两个程序调用，那么这个动态库只需要在内存中即可（因为加载器在加载动态库时，OS会先检查对应的动态库是否已经因为其他程序把这个动态库信息加载到了内存中，若没有加载到内存中，OS会将动态库载入内存，并将它的引用计数设置为1;如果已经加载到内存，仅将动态库的引用计数加1，无需重新加载），而且Java在不经过封装的情况下只能直接使用动态库，因此动态库又称为共享库。

ldd命令可以查看一个可执行程序依赖的共享库 ldd + 路径/可执行程序

编译创建静态库和动态库的步骤：

“-fpic”的作用是告诉gcc产生的代码不要包含对函数和变量具体内存位置的引用，因为现在还无法知道使用该代码的应用程序会将它连接到哪一段内存地址空间。只有这样编译出的xxx.o才可以被用于建立共享链接库。

对于静态库：

对于动态库：

不过这种方式在执行可执行程序的时候可能出现如下错误 ./a.out: error while loading shared libraries: libadd.so: cannot open shared object file: No such file or directory

解决步骤如下

在/etc/bash.bashrc文件中添加export LD_LIBRARY_PATH=$LD_LRBRARY_PATH:动态库的绝对路径。后source /etc/bash.bashrc

在/etc/ld.so.conf.d目录下创建一个以.conf为后缀的文件，在这个文件中添加上动态库的绝对路径，后执行sudo ldconfig

ldconfig命令的用途,主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下,搜索出可共享的动态链接库.

如果第一种的方式都配置完之后出现如下错误

这种错误说明编译器找不到需要链接的库，则还需要执行gcc xxxx.c 动态库完整路径/动态库。

Android 5.0及以下与6.0及以上时需要注意：若存在两个动态库libhello-jni.so 与 libTest.so。libhello-jni.so依赖于libTest.so (使用NDK下的ndk-depends可查看依赖关系)，则：

比如在已经编译好的静态库clib.a（或者动态库clib.so）中有一个test方法，而现在需要在另一个源文件crazy.c中使用clib.a中的test2方法中使用clib.a中的test方法，最后再把crazy.c打包成一个静态库或者动态库crazy.a或者crazy.so，如果clib是被以静态库引用的话则最终的crazy.a或者crazy.so库都会存在clib.a的所有方法实现（因为编译时就将所有符号加载到输出库），反之则只存在crazy.c的方法实现而不存在clib中的test方法（因为使用动态库是通过在运行时动态加载动态库的方法）

不同架构的CPU的指令集有所不同，不同 Android 设备可能会使用不同的 CPU，因此支持不同的指令集而需要生成的不同的CPU架构(ndk r17 只支持：armeabi-v7a, arm64-v8a, x86, x86_64)

查看Android设备 CPU架构的命令 adb shell cat /proc/cpuinfo adb shell getprop ro.product.cpu.abi

apk在安装的时候，如果手机是armeabi-v7a的，则会首先查看apk中是否存在armeabi-v7a目录，如果没有就会查找armeabi。所以必须保证cpu目录下so数量一致，如果目标是armeabi-v7a，但是拥有一个armeabi的，也可以把它放到armeabi-v7a目录下，但是反过来不行。

如果一开始新建Module时没有配置支持NDK，也可以在中途自己配置支持NDK，因为Gradle脚本中各种节点名称是BaseExtension.class中对应的方法名称，通过Groovy语法编写。 另外如果不知道各节点可以配置哪些属性，可以通过Java的形式来确定，其实就是Java对象的成员变量：

需要注意的是同一节点所在的层次不一样效果也会有所不同，比如在defaultConfig节点中的 externalNativeBuild的作用是指导编译源文件，而与defaultConfig同级的externalNativeBuild的作用是配置Native 构建监本的路径。

Android.mk